Managing transport occupants during transport events

ABSTRACT

An example operation may include one or more of identifying a target device has entered a transport and has initiated a transport event at a target location, applying permissions, associated with the target device, to the transport event, determining a transport event modification has occurred, when the transport has stopped moving for a predetermined period of time and one or more transport operations have occurred, prior to arriving at a transport event destination, determining whether the permissions permit the transport event modification, and notifying one or more registered devices associated with the target device of the transport event modification.

TECHNICAL FIELD

This application generally relates to managing transports and occupants,and more particularly, to managing transport occupants during transportevents.

BACKGROUND

Vehicles or transports, such as cars, motorcycles, trucks, planes,trains, scooters, etc., are being utilized by various occupants in avariety of ways. For example, a car or van can provide a taxi service,whether an automated transport or user operated transport. Users mayoperate their handheld computing devices to select a transport for aride to a particular destination. Transports may be identified andcontrolled by computing devices, such as a computer that controls thevehicle itself and/or via a controller device, such as a smartphone or acomputer managed by a vehicle operator.

Users of vehicles may be from all walks of life. The users may be youngor old and may require constant supervision by others. Also, thevehicles may offer numerous features from hard-coded software which maygovern an acceleration rate, speed, or suspension function to peripheralfeatures, such as temperature controlled seats, and multimediafunctions. As vehicles are being operated to provide transportationservices, the managing parties may desire to have optimal control overthe vehicle actions conducted during a vehicle event, such as a pick-upand/or drop-off event.

SUMMARY

One example embodiment may provide a method that includes one or more ofone or more of receiving a request from a requesting device to initiatea transport to perform a transport event at a target location,identifying the transport to perform the transport event, identifying atarget device associated with the transport event is located at thetarget location, receiving location updates of the transport and thetarget device at a server, determining the transport has initiated thetransport event based on the location updates of the transport,determining the target device and the transport are proximate to oneanother based on the location updates, and monitoring the locationupdates to identify whether the transport has deviated from a targettravel path area.

Another example embodiment may provide a system including a serverconfigure to perform one or more of receive a request from a requestingdevice to initiate a transport to perform a transport event at a targetlocation, identify the transport to perform the transport event,identify a target device associated with the transport event is locatedat the target location, receive location updates of the transport andthe target device at a server, determine the transport has initiated thetransport event based on the location updates of the transport,determine the target device and the transport are proximate to oneanother based on the location updates, and monitor the location updatesto identify whether the transport has deviated from a target travel patharea.

A further example embodiment may provide a non-transitory computerreadable medium comprising instructions, that when read by a processor,cause the processor to perform one or more of receiving a request from arequesting device to initiate a transport to perform a transport eventat a target location, identifying the transport to perform the transportevent, identifying a target device associated with the transport eventis located at the target location, receiving location updates of thetransport and the target device at a server, determining the transporthas initiated the transport event based on the location updates of thetransport, determining the target device and the transport are proximateto one another based on the location updates, and monitoring thelocation updates to identify whether the transport has deviated from atarget travel path area.

A yet further example embodiment may include a method comprising one ormore of identifying a target device has entered a transport and hasinitiated a transport event at a target location, applying permissions,associated with the target device, to the transport event, determining atransport event modification has occurred, when the transport hasstopped moving for a predetermined period of time and one or moretransport operations have occurred, prior to arriving at a transportevent destination, determining whether the permissions permit thetransport event modification, and notifying one or more registereddevices associated with the target device of the transport eventmodification.

A yet further example embodiment may include a system comprising aserver configured to perform one or more of identify a target device hasentered a transport and has initiated a transport event at a targetlocation, apply permissions, associated with the target device, to thetransport event, determine a transport event modification has occurred,when the transport has stopped movement for a predetermined period oftime and one or more transport operations have occurred, prior toarrival at a transport event destination, determine whether thepermissions permit the transport event modification, and notify one ormore registered devices associated with the target device of thetransport event modification.

A yet further example embodiment may include a non-transitory computerreadable medium comprising instructions, that when read by a processor,cause the processor to perform one or more of identifying a targetdevice has entered a transport and has initiated a transport event at atarget location, applying permissions, associated with the targetdevice, to the transport event, determining a transport eventmodification has occurred, when the transport has stopped moving for apredetermined period of time and one or more transport operations haveoccurred, prior to arriving at a transport event destination,determining whether the permissions permit the transport eventmodification, and notifying one or more registered devices associatedwith the target device of the transport event modification.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates a network diagram of a transport access requestconfiguration, according to example embodiments.

FIG. 1B illustrates a blockchain configuration for storing blockchaintransaction data, according to example embodiments.

FIG. 1C illustrates a transport and user profile identification andselection procedure, according to example embodiments.

FIG. 1D illustrates a network diagram of a transport event modificationconfiguration, according to example embodiments.

FIG. 2A illustrates an example peer node configuration, according toexample embodiments.

FIG. 2B illustrates a shared ledger configuration, according to exampleembodiments.

FIG. 3A illustrates a transport event configuration, according toexample embodiments.

FIG. 3B illustrates a flow diagram of transport event monitoring,according to example embodiments.

FIG. 3C illustrates another flow diagram of transport event monitoring,according to example embodiments.

FIG. 4A illustrates a transport event setup and monitoring configurationflow diagram, according to example embodiments.

FIG. 4B illustrates another transport event setup and monitoringconfiguration, according to example embodiments.

FIG. 4C illustrates yet another transport event setup and monitoringconfiguration, according to example embodiments.

FIG. 5A illustrates an example blockchain transport configuration,according to example embodiments.

FIG. 5B illustrates another example blockchain transport configuration,according to example embodiments.

FIG. 5C illustrates a further example blockchain transportconfiguration, according to example embodiments.

FIG. 6 illustrates an example data block, according to exampleembodiments.

FIG. 7 illustrates an example system that supports one or more of theexample embodiments.

DETAILED DESCRIPTION

It will be readily understood that the instant components, as generallydescribed and illustrated in the figures herein, may be arranged anddesigned in a wide variety of different configurations. Thus, thefollowing detailed description of the embodiments of at least one of amethod, apparatus, non-transitory computer readable medium and system,as represented in the attached figures, is not intended to limit thescope of the application as claimed but is merely representative ofselected embodiments.

The instant features, structures, or characteristics as describedthroughout this specification may be combined in any suitable manner inone or more embodiments. For example, the usage of the phrases “exampleembodiments”, “some embodiments”, or other similar language, throughoutthis specification refers to the fact that a particular feature,structure, or characteristic described in connection with the embodimentmay be included in at least one embodiment. Thus, appearances of thephrases “example embodiments”, “in some embodiments”, “in otherembodiments”, or other similar language, throughout this specificationdo not necessarily all refer to the same group of embodiments, and thedescribed features, structures, or characteristics may be combined inany suitable manner in one or more embodiments. In the diagrams, anyconnection between elements can permit one-way and/or two-waycommunication even if the depicted connection is a one-way or two-wayarrow. In the current application, a transport may include one or moreof cars, trucks, motorcycles, scooters, bicycles, boats, recreationalvehicles, planes, and any object that may be used to transport peopleand or goods from one location to another.

In addition, while the term “message” may have been used in thedescription of embodiments, the application may be applied to many typesof network data, such as, packet, frame, datagram, etc. The term“message” also includes packet, frame, datagram, and any equivalentsthereof. Furthermore, while certain types of messages and signaling maybe depicted in exemplary embodiments they are not limited to a certaintype of message, and the application is not limited to a certain type ofsignaling.

Example embodiments provide methods, systems, components, non-transitorycomputer readable media, devices, and/or networks, which provide atleast one of: a transport (also referred to as a vehicle herein) a datacollection system, a verification system, and a vehicle datadistribution system. The vehicle status data, received in the form ofcommunication update messages, such as wireless data networkcommunications and/or wired communication messages, may be received andprocessed to identify vehicle/transport status conditions and providesafety and optimal transport alerts to assist with vehicle travel. Forexample, a first user profile may be applied to a particulartransport/vehicle to monitor and authorize the vehicle for another userat a remote location.

Within the communication infrastructure, a decentralized database is adistributed storage system which includes multiple nodes thatcommunicate with each other. A blockchain is an example of adecentralized database which includes an append-only immutable datastructure (i.e. a distributed ledger) capable of maintaining recordsbetween untrusted parties. The untrusted parties are referred to hereinas peers, nodes or peer nodes. Each peer maintains a copy of thedatabase records and no single peer can modify the database recordswithout a consensus being reached among the distributed peers. Forexample, the peers may execute a consensus protocol to validateblockchain storage entries, group the storage entries into blocks, andbuild a hash chain via the blocks. This process forms the ledger byordering the storage entries, as is necessary, for consistency. In apublic or permission-less blockchain, anyone can participate without aspecific identity. Public blockchains can involve cryptocurrencies anduse consensus based on various protocols such as proof of work (PoW). Onthe other hand, a permissioned blockchain database provides a systemwhich can secure interactions among a group of entities which share acommon goal, but which do not or cannot fully trust one another, such asbusinesses that exchange funds, goods, information, and the like. Theexample embodiments of the instant application can function in apermissioned and/or a permissionless blockchain setting.

Smart contracts are trusted distributed applications which leveragetamper-proof properties of the shared or distributed ledger (i.e., whichmay be in the form of a blockchain) database and an underlying agreementbetween member nodes which is referred to as an endorsement orendorsement policy. In general, blockchain entries are “endorsed” beforebeing committed to the blockchain while entries which are not endorsedare disregarded. A typical endorsement policy allows smart contractexecutable code to specify endorsers for an entry in the form of a setof peer nodes that are necessary for endorsement. When a client sendsthe entry to the peers specified in the endorsement policy, the entry isexecuted to validate the entry. After validation, the entries enter anordering phase in which a consensus protocol is used to produce anordered sequence of endorsed entries grouped into blocks.

Nodes are the communication entities of the blockchain system. A “node”may perform a logical function in the sense that multiple nodes ofdifferent types can run on the same physical server. Nodes are groupedin trust domains and are associated with logical entities that controlthem in various ways. Nodes may include different types, such as aclient or submitting-client node which submits an entry-invocation to anendorser (e.g., peer), and broadcasts entry-proposals to an orderingservice (e.g., ordering node). Another type of node is a peer node whichcan receive client submitted entries, commit the entries and maintain astate and a copy of the ledger of blockchain entries. Peers can alsohave the role of an endorser, although it is not a requirement. Anordering-service-node or orderer is a node running the communicationservice for all nodes, and which implements a delivery guarantee, suchas a broadcast to each of the peer nodes in the system when committingentries and modifying a world state of the blockchain, which is anothername for the initial blockchain entry which normally includes controland setup information.

A ledger is a sequenced, tamper-resistant record of all statetransitions of a blockchain. State transitions may result from smartcontract executable code invocations (i.e., entries) submitted byparticipating parties (e.g., client nodes, ordering nodes, endorsernodes, peer nodes, etc.). An entry may result in a set of assetkey-value pairs being committed to the ledger as one or more operands,such as creates, updates, deletes, and the like. The ledger includes ablockchain (also referred to as a chain) which is used to store animmutable, sequenced record in blocks. The ledger also includes a statedatabase which maintains a current state of the blockchain. There istypically one ledger per channel. Each peer node maintains a copy of theledger for each channel of which they are a member.

A chain is an entry log which is structured as hash-linked blocks, andeach block contains a sequence of N entries where N is equal to orgreater than one. The block header includes a hash of the block'sentries, as well as a hash of the prior block's header. In this way, allentries on the ledger may be sequenced and cryptographically linkedtogether. Accordingly, it is not possible to tamper with the ledger datawithout breaking the hash links. A hash of a most recently addedblockchain block represents every entry on the chain that has comebefore it, making it possible to ensure that all peer nodes are in aconsistent and trusted state. The chain may be stored on a peer nodefile system (i.e., local, attached storage, cloud, etc.), efficientlysupporting the append-only nature of the blockchain workload.

The current state of the immutable ledger represents the latest valuesfor all keys that are included in the chain entry log. Because thecurrent state represents the latest key values known to a channel, it issometimes referred to as a world state. Smart contract executable codeinvocations execute entries against the current state data of theledger. To make these smart contract executable code interactionsefficient, the latest values of the keys may be stored in a statedatabase. The state database may be simply an indexed view into thechain's entry log, it can therefore be regenerated from the chain at anytime. The state database may automatically be recovered (or generated ifneeded) upon peer node startup, and before entries are accepted.

A blockchain is different from a traditional database in that theblockchain is not a central storage but rather a decentralized,immutable, and secure storage, where nodes must share in changes torecords in the storage. Some properties that are inherent in blockchainand which help implement the blockchain include, but are not limited to,an immutable ledger, smart contracts, security, privacy,decentralization, consensus, endorsement, accessibility, and the like.

Example embodiments provide a way for applying a user profile status tothe vehicle when a user requests access to a vehicle for the user or foranother user, such as in the example of a parent or guardian requestinga vehicle to provide transportation services for another user, such as asubordinate party (e.g., child, elderly person, etc.). Also, sensorinformation may be identified to identify whether the vehicle isoperating safely and whether the occupant user is safe based on basicsafety tests during the vehicle access period. Information collectedbefore, during and/or after a vehicle's operation may be collected andstored in a transaction on a shared ledger, which may be generated andcommitted to the immutable ledger as determined by a permission grantingconsortium, and thus in a “decentralized” manner, such as via ablockchain membership group. Each interested party (i.e., driver, remotedriver, company, agency, occupant, etc.) may want to limit the exposureof private information, and therefore the blockchain and itsimmutability can limit the exposure and manage permissions for eachparticular user vehicle profile. A smart contract may be used to providecompensation, permission determination, quantify a user profile score,apply vehicle event permissions, identify a collision event, identify asafety concern event, identify parties to the event and providedistribution to registered entities seeking access to such vehicle eventdata. Also, the results may be identified, and the necessary informationcan be shared among the registered companies and/or individuals based ona “consensus” approach associated with the blockchain. Such an approachcould not be implemented on a traditional centralized database.

The instant application includes vehicle event and/or correspondingcomputer controllers that are configured to share relevant data that islikely to assist other vehicles, detect/avoid dangerous conditions, andassist third parties with identifying those parties to certain vehicleevents. Data shared and received may be stored in a database whichmaintains data in one single database (e.g., database server) andgenerally at one particular location. This location is often a centralcomputer, for example, a desktop central processing unit (CPU), a serverCPU, or a mainframe computer. Information stored on a centralizeddatabase is typically accessible from multiple different points. Acentralized database is easy to manage, maintain, and control,especially for purposes of security because of its single location.Within a centralized database, data redundancy is minimized as a singlestoring place of all data also implies that a given set of data only hasone primary record.

FIG. 1A illustrates a network diagram of a transport access requestconfiguration, according to example embodiments. Referring to FIG. 1A,the network diagram 100 includes a user 104 accessing a user device 102to request access to a vehicle 120 on behalf of another user 108operating a target user device 106. The vehicle 120 may be a rented,owned, partially owned (i.e., subject to other owners), autonomouslydriven by a non-present driver, semi-autonomously driven by a driver ordriven by a conventional manual vehicle operator. The vehicle may acceptthe user request sent from the user device 102 as managed by a vehicleservice server 130, which receives the request, identifies an availablevehicle and creates a new transport event 132. The server 130 mayidentify the user profile for the user 104 and may then apply the userprofile to the vehicle 120 prior to a driving event. The vehicle 120 mayhave a set of features and services available to the occupants, however,the user profile of the requesting entity may require certain featuresbe limited to only a sub-set of those features given a user status(e.g., parent requesting the vehicle for a child). Also, certainrequirements may be required, such as child safety measures prior to thevehicle being selected for pick-up and drop-off of the subordinate user108.

In operation, as the user's device 104 is identified as having sent arequest to access the vehicle, the vehicle 120 may apply the userprofile(s) of the requesting entity and/or the target entity 108 to thevehicle. The vehicle features required may be identified to providechild safety measures, security measures from third parties trying toaccess the vehicle while in route, etc. For example, a parent mayrequest a vehicle pickup their child at a school so the child can bedriven home. The location restrictions may permit the vehicle to driveto the school, identify the child via the child's description and/or viaa smart device operated by the child (e.g., smart tag, smartphone,smartwatch, etc.), receive the child, and drive the child home. Oneexample of a vehicle restriction may require the vehicle to not permitthe doors to open until the vehicle is at the home location, not permitthe vehicle to drive a route that is not the preferred route, not permitthe vehicle to move past a particular distance from the child's home,etc. Other features may include restrictions to the speed andacceleration features, which may not permit the user to accelerate pasta certain acceleration rate or speed in order to reduce the risk of acollision. In another example, if the passenger/occupant does notrequire such restrictions, the vehicle may be permitted to drive atfaster speeds, greater distances, and/or provide media options tooccupants not previously available to children passengers. The vehiclemay have a customized profile sent from the vehicle server 130 listingthe features which are permissible. The list may be downloaded to thevehicle and applied as a vehicle profile file that is customized basedon the passenger restrictions/permissions. Vehicle sensors may monitorthe vehicle actions to ensure the restrictions are followedappropriately.

Any of the vehicles may include sensors on any portion of the interiorand/or exterior of a vehicle. The sensors may be hardwired to a centralcontroller or other processor of the vehicle or may be in wirelesscommunication with a central controller of the vehicle's computer viavarious wireless communication protocols. The data may be transmittedfrom the central controller, such as an on-board computer, a user'ssmartphone, a cellular compatible device, etc. The sensor content anddifferent sensor data types may include one or more of a radio stationselection, recorded audio, mobile device usage within the vehicle,telephone calls conducted inside the vehicle, browser history of atleast one of the computing devices, purchases conducted via at least onecomputing device inside the vehicle, movement of the vehicle, navigationof the vehicle, a collision of the vehicle, speed of the transport,acceleration of the vehicle, diagnostics associated with the transportincluding battery charge level, gasoline level, oil level, temperatureof the vehicle, location of the vehicle, detected traffic near thevehicle, information regarding other vehicles, etc.

The types of sensors include one or more of movement sensors, sonarsensors, lidar sensors, accelerometers, touch sensors, proximitysensors, temperature sensors, speed sensors, sound sensors, infraredsensors, collision sensors, level sensors, tire pressure sensors,location determination sensors, ultrasonic sensors, camera sensors,activity sensors, chemical sensors, fluid sensors, pressure sensors,optical sensors and biometric sensors.

Autonomous vehicles may be regulated where sensor data is mandated forvarious reasons since operation of the vehicle is controlled by acomputer and not necessarily a person. As a result, the sharing of thesensor data gathered by autonomous vehicles may be required by variousagencies and third parties to ensure safety measures. As notedpreviously, the vehicle 120 may be a vehicle operated by a human driveror an autonomous vehicle operated by a computer and/or remote agentdesigned for users to ride in during a transport event. The vehiclesensor data may be collected via a plurality of the vehicle sensors. Thecontroller device (i.e., on-board computer and/or user smartphone, etc.)may identify the sensor type, sensor identifier and instances of sensordata received for those parameters. The collection of sensor data maycreate one or more sets of sensor data. For example, sensors S1, S2, S3. . . Sn, may generate sensor data sets SD1, SD2, SD3 . . . SDn. Thosesensor data sets may include multiple iterations of sensor data over afixed period of time (e.g., milliseconds, seconds, minutes, hours, etc.)or short instances of extreme measurements, such as only instances oflarge deviations from expected values to identify, for example, anaccident, a hole in the road, braking, extreme conditions or maneuvers,etc.

Owners of autonomous/non-autonomous vehicles (or occupants of thevehicles) may register their personal profiles in a shared ledger orother data management system so the information collected during sensorcollection efforts may be shared and the owner's profile and/or vehiclemay be credited with a predetermined value also identified in the sharedledger, via a smart contract. The smart contract may identify theparties of the agreement, permissions for vehicle occupants, types ofdata, current profile statuses and other parameters. The immutability ofthe sensor data may also be preserved via the shared ledger format of ablockchain.

Referring again to FIG. 1A, when a user 102 accesses a vehicle serviceserver 130 via their smartphone device 102, the user profile may beidentified by the server 130, to identify the user, their profile and/orcurrent/previous statuses (e.g., parent, guardian, young occupant, olderoccupant, etc.). The vehicle 120 is selected if it is available for useand can provide the safety measures or requirements necessary to pick-upthe target user 108 at the target location. An event 132 is created andany trusted devices 112 (e.g., parents, teachers, babysitters, schools,etc.) may be notified accordingly of the event and any subsequent eventalerts (e.g., deviations, collisions, completed trips, modifications tothe vehicle event, etc.).

FIG. 1B illustrates a blockchain configuration for storing blockchaintransaction data, according to example embodiments. Referring to FIG.1B, the example configuration 150 provides for the vehicle 120, the userdevices 102/106 and the server 130 sharing information with adistributed ledger (i.e., blockchain) 140. As the events occur, such asthe vehicle request, vehicle identification, user profile retrieval,user profile/access status identification, rules and permissions beingapplied to the vehicle, vehicle event modification, vehicle operationalbehavior monitoring, etc., a smart contract is used to invoke rules,information gathering and terms for the vehicle events. The blockchaintransaction data 142 is saved for each transaction, such as the accessevent, the subsequent updates to a vehicle status, event modifications,etc. The transactions may include the parties, the requirements (e.g.,18 years of age, legal guardian of occupant, valid driver's license,etc.), compensation levels, the distance traveled during the event, theregistered recipients permitted to access the event, rights/permissions,sensor data retrieved during the event to log details of the event andmodify a user's vehicle status, and thresholds used to makedeterminations about whether the event should be permitted, should beterminated, was completed, etc.

FIG. 1C illustrates a transport and user profile identification andselection procedure, according to example embodiments. Referring to FIG.1C, the configuration 160 includes the server 130 being accessed toidentify user profile information 164 and vehicle information 162. Thevehicle profiles may store information, such as a vehicle's features,such as peripheral features, entertainment features, safety features,etc., which may or may not be permitted to be used while operating thevehicle based on the settings of the user profile(s) 164. For example,in a particular scenario, a selected vehicle 166 may be paired with oneor more vehicle events 172. The initial vehicle event 172 may be setupby a parent user for a child user. The permissions, restrictions andother information pertaining to the vehicle event may be 172 may besetup as a trip with no stops permitted 171, no opening or closing ofthe doors and one known target destination 173, such as the child/parenthome location. All the rules and restrictions may be setup as an eventfile that is created by the server 130 based on the rules andpermissions in the user profiles 164 and which is then applied to thevehicle 166. The vehicle door statuses may be identified by the vehicleand controlled by the vehicle controller device to remain closed untilthe vehicle enters the area near the target destination.

In one specific example, the child or parent may attempt to modify theevent 174 to include an additional stop 177 or a new destination, suchas due to a change in plans, etc. This new modified stop may beidentified 175 as a single stop that is added to the destinations or asa new destination. For example, the rules may identify the stop as agrocery store pick-up event, where the trunk is permitted to be openedbut not the vehicle doors so the groceries can be picked-up in thevehicle by a grocery curb-side service and placed in the trunk, however,the child may be safe inside since the doors will not open at thisintermediate event 174. Another example of a modified event 176 mayinclude the child requesting to go to a friend's house to pickup afriend on the way home for a visit. The second stop 178 may beauthorized as a new target destination 179 by the parent or othertrusted devices 112, such as the mom, dad, grandparent, the friend'smom, dad, etc. The modified vehicle event 176 may require a confirmationby one or more of the trusted party's devices prior to being acceptedand identified by the current vehicle event 172. If the confirmationdoes not come in a specific period of time, the event request may becancelled.

FIG. 1C illustrates a transport and user profile identification andselection procedure, according to example embodiments.

FIG. 1D illustrates a network diagram of a transport event modificationconfiguration, according to example embodiments. Referring to FIG. 1D,the example 180 continues with the example of FIG. 1C, where a childuser 108 is being driven to a home destination 173. However, the parentmay submit a request to have the vehicle pick-up the groceries at thelocal store's curbside service 177. The vehicle 120 may travel to thestore, not permit the doors to open, monitor the child's device toensure the child has not attempted to leave the vehicle by tracking thelocation information of both the vehicle and the child's device 106. Inthe event that the child has attempted to travel to a friend's house tostay at that location instead and/or pick-up a friend and bring thefriend home, the new target destination/intermediate destination 179 maybe added to the vehicle's event route assuming approval for such arequest is approved by a registered and trusted device 112.

FIG. 2A illustrates a blockchain architecture configuration 200,according to example embodiments. Referring to FIG. 2A, the blockchainarchitecture 200 may include certain blockchain elements, for example, agroup of blockchain member nodes 202-206 as part of a permissionedblockchain group 210. The permissioned blockchain is not accessible toall parties but only to those members with permissioned access to theblockchain data. The blockchain nodes participate in a number ofactivities, such as blockchain entry addition and validation process(consensus). One or more of the blockchain nodes may endorse entriesbased on an endorsement policy and may provide an ordering service forall blockchain nodes. A blockchain node may initiate a blockchain action(such as an authentication) and seek to write to a blockchain immutableledger stored in the blockchain, a copy of which may also be stored onthe underpinning physical infrastructure. In other embodiments, theblockchain group 210 may be a permissionless blockchain group.

The blockchain transactions 220 are stored in memory of computers as thetransactions are received and approved by the consensus model dictatedby the members' nodes. Approved transactions 226 are stored in currentblocks of the blockchain and committed to the blockchain via a committalprocedure which includes performing a hash of the data contents of thetransactions in a current block and referencing a previous hash of aprevious block. Within the blockchain, one or more smart contracts 230may exist that define the terms of transaction agreements and actionsincluded in smart contract executable application code 232. The code maybe configured to identify whether requesting entities are registered toreceive vehicle access, what features they are entitled/required toreceive given their profile statuses and whether to monitor theiractions in subsequent events. For example, when an event occurs and auser is riding in the vehicle, the sensor data monitoring may betriggered, and a certain parameter, such as a vehicle velocity, may beidentified as being above/below a particular threshold for a particularperiod of time, then the result may be a change to a current statuswhich requires an alert to be sent to the managing party (i.e., parent,server, etc.) so the deviation can be corrected and noted. The vehiclesensor data collected may be based on types of sensor data used tocollect information about vehicle's driving. The sensor data may also bethe basis for the vehicle event data 234, such as a location(s) to betraveled, an average speed, a top speed, acceleration rates, whetherthere were any collisions, was the expected route taken, whether safetymeasures in place, etc. All such information may be the basis of smartcontract terms 230, which are then stored in a blockchain.

FIG. 2B illustrates a shared ledger configuration, according to exampleembodiments. Referring to FIG. 2B, the blockchain logic example 250includes a blockchain application interface 252 as an API or plug-inapplication that links to the computing device and execution platformfor a particular transaction. The blockchain configuration 250 mayinclude one or more applications which are linked to applicationprogramming interfaces (APIs) to access and execute storedprogram/application code (e.g., smart contract executable code, smartcontracts, etc.) which can be created according to a customizedconfiguration sought by participants and can maintain their own state,control their own assets, and receive external information. This can bedeployed as an entry and installed, via appending to the distributedledger, on all blockchain nodes.

The smart contract application code 254 provides a basis for theblockchain transactions by establishing application code which whenexecuted causes the transaction terms and conditions to become active.The smart contract 230, when executed, causes certain approvedtransactions 226 to be generated, which are then forwarded to theblockchain platform 262. The platform includes a security/authorization268, computing devices which execute the transaction management 266 anda storage portion 264 as a memory that stores transactions and smartcontracts in the blockchain.

The blockchain platform may include various layers of blockchain data,services (e.g., cryptographic trust services, virtual executionenvironment, etc.), and underpinning physical computer infrastructurethat may be used to receive and store new entries and provide access toauditors which are seeking to access data entries. The blockchain mayexpose an interface that provides access to the virtual executionenvironment necessary to process the program code and engage thephysical infrastructure. Cryptographic trust services may be used toverify entries such as asset exchange entries and keep informationprivate.

The blockchain architecture configuration of FIGS. 2A and 2B may processand execute program/application code via one or more interfaces exposed,and services provided, by the blockchain platform. As a non-limitingexample, smart contracts may be created to execute reminders, updates,and/or other notifications subject to the changes, updates, etc. Thesmart contracts can themselves be used to identify rules associated withauthorization and access requirements and usage of the ledger. Forexample, the information may include a new entry, which may be processedby one or more processing entities (e.g., processors, virtual machines,etc.) included in the blockchain layer. The result may include adecision to reject or approve the new entry based on the criteriadefined in the smart contract and/or a consensus of the peers. Thephysical infrastructure may be utilized to retrieve any of the data orinformation described herein.

Within smart contract executable code, a smart contract may be createdvia a high-level application and programming language, and then writtento a block in the blockchain. The smart contract may include executablecode which is registered, stored, and/or replicated with a blockchain(e.g., distributed network of blockchain peers). An entry is anexecution of the smart contract code which can be performed in responseto conditions associated with the smart contract being satisfied. Theexecuting of the smart contract may trigger a trusted modification(s) toa state of a digital blockchain ledger. The modification(s) to theblockchain ledger caused by the smart contract execution may beautomatically replicated throughout the distributed network ofblockchain peers through one or more consensus protocols.

The smart contract may write data to the blockchain in the format ofkey-value pairs. Furthermore, the smart contract code can read thevalues stored in a blockchain and use them in application operations.The smart contract code can write the output of various logic operationsinto the blockchain. The code may be used to create a temporary datastructure in a virtual machine or other computing platform. Data writtento the blockchain can be public and/or can be encrypted and maintainedas private. The temporary data that is used/generated by the smartcontract is held in memory by the supplied execution environment, thendeleted once the data needed for the blockchain is identified.

A smart contract executable code may include the code interpretation ofa smart contract, with additional features. As described herein, thesmart contract executable code may be program code deployed on acomputing network, where it is executed and validated by chainvalidators together during a consensus process. The smart contractexecutable code receives a hash and retrieves from the blockchain a hashassociated with the data template created by use of a previously storedfeature extractor. If the hashes of the hash identifier and the hashcreated from the stored identifier template data match, then the smartcontract executable code sends an authorization key to the requestedservice. The smart contract executable code may write to the blockchaindata associated with the cryptographic details.

FIG. 3A illustrates a transport access system configuration, accordingto example embodiments. Referring to FIG. 3A, the system 300 provides atransport/vehicle 310, which may be requested via a user submittedrequest to initiate a vehicle event 312, which may be managed by amanagement server 320. The server 320 may identify a particular vehicle310 being requested, such as one owned by a user, or one that isselected for purchase, rent, or is available for rental/taxi purposes.The user profile of the requesting entity may also be retrieved to applyto the vehicle 310 along with a set of defined vehicle features whichare required/prohibited. The procedure for accessing and receiving avehicle may be managed by a smart contract 316 associated with ablockchain. The smart contract may be executed 318 to enable a newvehicle event. The vehicle that is ideal for such an event may beidentified as available, and target device may be identified andmonitored via location updates 314. This process may load the user'sprofile on the vehicle and/or a customized vehicle event file thatincludes requirements retrieved from the user's profile and applied to avehicle computer, via the smart contract 322, so the correct featuresare enabled/disabled by the central vehicle controller. Duringoperation, such as once the target user has started moving with thevehicle, a request may originate from the target user or any of thetrusted users to modify the current vehicle event data 324. For example,a stop at the grocery store on the way home may be requested, or thepassenger may request to stop at a friend's house or other location. Thetarget user could be a child or an elderly person or anyone thatrequires a guardian to monitor their well-being. The modification to theevent may require permission from a trusted user and/or a reference tothe rules or permissions which are stored in memory. If the modificationis possible/permissible 326, then those permissible modifications may bepermitted 328 and the event may be changed to include additional data inthe server 320 and vehicle 310 to reflect those changes in route, etc.As the events are conducted, updates to the blockchain 330 may beperformed 329 to store event data.

FIG. 3B illustrates a user profile monitoring configuration, accordingto example embodiments. Referring to FIG. 3B, the flow diagram 340includes a process to track a target user and apply specific event rulesand permission to a vehicle event. The process may include receivingrequest 342 from a guardian or other overseeing party to engage a targetuser with a vehicle transport event. The transport selected must adhereto requirements, such as handicap features, child safety doors andseats, etc. The transport is then dispatched to head to the location ofthe target user which may be identified from a target user devicecarried by the target user. When the vehicle and user are at a samelocation 344 the event is initiated 346 based on the assumption the useris now in the vehicle. As the event progresses, the location of thevehicle and target user device are continuously monitored 346 forcompliance, if the target user device and vehicle are not in the samelocation 352, then alerts may be sent to all interested parties 353.Otherwise, the process continues to determine whether other devices arerequesting access to the same vehicle 354. This may be a prohibitedaction or at least most persons may be prohibited from entering thevehicle absent an exception list of registered user devices. The listmay be stored in the server and retrieved 356 to identify thepermissions and established information pertaining to the target user.If, during the decision process 358, the other user/user device is notpermitted, the request is denied 364, the door will not open and thevehicle will not travel to that person's location based on their device.If they are permitted (e.g., parent, teacher, friend, etc.), and areknown to the system, then they may be permitted to enter the vehicle362.

FIG. 3C illustrates another flow diagram of transport event monitoring,according to example embodiments. Referring to FIG. 3C, the examplemethod 370 provides an example of a target device receiving a transportevent service and attempting to modify the event in route to aparticular destination. In operation, the target device is identified372, the permissions which may exist for that target device are thenapplied 374. The permissions which dictate what the target device is andis not permitted to do with regard to a transport event may be setup bya guardian party that has authority over that particular user's actions.For example, a minor may be able to call a vehicle service but may notbe able to head towards a downtown area without explicitly documentedpermission. However, the target user may be able to make requests duringthe transport event and attempt to modify a vehicle event 376. Forexample, the target user may seek to visit a friend, go by the store,etc., on the way home. The modification may be in the form of a requestthat is received and processed to determine if the location requested ispermitted based on permissions 378. If not, an alert is transmitted toall interested parties 373, which may override the automated decision bya trusted device party accepting the request. If the modification isacceptable, the permissible transport routes are identified, and theevent is modified 382 to reflect the necessary changes to the route. Theregistered devices may be notified of the changes 384, such as a textmessage or in-application alert. Since the criteria has changed,additional monitoring and alerts may be required to monitor thevehicle's activities, such as did a door open when it should not have,did the trunk open to receive groceries, is the expected length of time(e.g., five minutes at the store, at a friend's house, etc.) of vehicleidle status exceeded or not, etc. The expected time periods, actions andother information are stored in a template file and measured against theactual data received to identify deviations 386. If the deviations areidentified, an alert is sent, and if not, the modified event activitiesare deemed acceptable and process continues to monitor until completed388. All identified events are logged in a blockchain transaction. Thesmart contract may have rules and the adherence or deviation from therules may be logged for reference purposes.

FIG. 4A illustrates a transport event setup and monitoring configurationflow diagram, according to example embodiments. Referring to FIG. 4A,the method 400 may include receiving a request from a requesting deviceto initiate a transport to perform a transport event at a targetlocation 412, identifying the transport to perform the transport event414, identifying a target device associated with the transport event islocated at the target location 416, receiving location updates of thetransport and the target device at a server 418, determining thetransport has initiated the transport event based on the locationupdates of the transport 422, determining the target device and thetransport are proximate to one another based on the location updates424, and monitoring the location updates to identify whether thetransport has deviated from a target travel path area 426.

The method may also include determining another device has requestedaccess to the transport, responsive to receiving the another devicerequest, retrieving a list of trusted devices, determining whether theanother device is permitted to access the transport during the transportevent based on the list of trusted devices, when the another device isincluded in the list of trusted devices, modifying the transport eventto stop at the another device's location, and notifying the requestingdevice of the another device and the modified transport event. Whenanother device is not included in the list of trusted devices, denyingthe request to access the transport. The method may also includedetermining the target device and the transport are not proximate to oneanother based on the location updates, determining whether the targetdevice is located at a target destination, and transmitting aconfirmation message to the requesting entity to confirm the transportevent has completed. The method may also include determining a locationof the target device has deviated from the target travel path area,transmitting a notification to the requesting device indicating thedeviation, transmitting an instruction to the transport to correct thedeviation, and receiving a confirmation that the transport has correctedthe deviation.

The method may also include retrieving a smart contract from adistributed ledger, invoking the smart contract responsive to receivingthe request for the transport event, and determining, from the smartcontract, the target device requires a specific category of transportand is permitted to be transported to one or more identified destinationlocations. The method may also include creating a blockchain transactionwith a date of the transport event, a time of the transport event, thetarget location, a target destination and transport identificationinformation, and storing the blockchain transaction in the distributedledger.

FIG. 4B illustrates another transport event setup and monitoringconfiguration, according to example embodiments. Referring to FIG. 4B,the method 450 includes identifying a target device has entered atransport and has initiated a transport event at a target location 452,applying permissions, associated with the target device, to thetransport event 454, determining a transport event modification hasoccurred, when the transport has stopped moving for a predeterminedperiod of time and one or more transport operations have occurred, priorto arriving at a transport event destination 456, determining whetherthe permissions permit the transport event modification 462 andnotifying one or more registered devices associated with the targetdevice of the transport event modification 464.

The method may also include receiving a request to perform the transportevent modification during the transport event, determining whether therequest originated from one or more of the registered devices, andresponsive to determining the request originated from one or more of theregistered devices, permitting the transport event modification, andresponsive to permitting the transport event modification, addinganother destination location to the transport event as a nextdestination for the transport, and determining an estimated amount oftransport stop time and one or more of the transport operations whichare expected to occur during the transport stop time. The method mayalso include identifying the transport has arrived at the nextdestination, determining whether an amount of transport stop time hasexceeded the estimated amount of transport stop time, determiningwhether the one or more expected transport operations have occurredduring the transport stop time, and notifying one or more of theregistered devices when at least one of the amount of transport stoptime has exceeded the estimated amount of transport stop time and atleast one prohibited transport operation has occurred during thetransport stop time. The method may also include receiving a request toperform the transport event modification during the transport event,determining the request originated from the target device, determiningthe request comprises a modified destination, retrieving a user deviceprofile associated with a user device associated with the modifieddestination, transmitting a request for confirmation of the transportevent modification to the user device associated with the modifieddestination, transmitting a request for permission to the one or moreregistered devices, and responsive to receiving a confirmation from theuser device associated with the modified destination and a permissionresponse from the one or more registered devices, permitting thetransport event modification. The method may also include retrieving asmart contract from a distributed ledger, invoking the smart contractresponsive to identifying the transport event, and determining, from thesmart contract, the target device requires a specific category oftransport and is permitted to be transported to one or more identifieddestination locations. The method may also provide creating a blockchaintransaction comprising a date of the transport event, a time of thetransport event, the target location, a transport event destination andtransport identification information, and storing the blockchaintransaction in the distributed ledger.

FIG. 4C illustrates yet another transport event setup and monitoringconfiguration, according to example embodiments. The method 470 mayinclude identifying a target device associated with a first occupant hasentered a transport and has initiated a transport event at a targetlocation 472, applying permissions, associated with the target device,to the transport event 474, determining a transport event modificationhas occurred, when the transport has stopped moving for a predeterminedperiod of time at an intermediate destination and one or more transportoperations have occurred, prior to arriving at a transport eventdestination 476, identifying a new potential occupant at theintermediate destination 478, performing an authorization of the newpotential occupant based on an occupant screening procedure 482,determining whether the permissions permit the new potential occupantbased on the occupant screening procedure 484, and notifying one or moreregistered devices associated with the target device of the newpotential occupant 486.

In this example, the new potential occupant may be authorized by abiometric data input requirement, such as a facial scan, a retina scan,a fingerprint, a voice sample, etc. The potential occupant may providesuch information to his or her device, a scanner on the vehicle, etc.The user may be identified, and the vehicle may open to permit access ofthe new user occupant, or, the user may not receive access depending onthe permissions of the transport event.

FIG. 5A illustrates an example blockchain vehicle configuration 500 formanaging blockchain transactions associated with a vehicle, according toexample embodiments. Referring to FIG. 5A, as a particulartransport/vehicle 120 is engaged in transactions, such as servicetransactions (e.g., vehicle service, dealer transactions,delivery/pickup, transportation services, etc.), the vehicle may receivevalues 510 and/or expel/transfer values 512 according to a servicetransaction(s). The transaction module 520 may record information, suchas parties, credits, service descriptions, date, time, location,results, notifications, unexpected events, etc. Those transactions inthe transaction module 520 may be replicated into a blockchain 530 whichis managed by a remote server and/or remote blockchain peers, amongwhich the vehicle itself may represent a blockchain member and/orblockchain peer. In other embodiments, the blockchain 530 resides on thevehicle 120. Responsibility for value/credits received and/ortransferred can be determined by the system, the requesting device, orthe transport as described herein.

FIG. 5B illustrates an example blockchain vehicle configuration 540 formanaging blockchain transactions between a service center and a vehicle,according to example embodiments. In this example, the vehicle 120 mayhave driven itself to a service center 542 (e.g., automotive dealer,local service stop, delivery pickup center, etc.) because the vehicleneeds service and/or needs to stop at a particular location. The servicecenter 542 may register the vehicle for a service call at a particulartime, with a particular strategy, such as oil change, battery charge orreplacement, tire change or replacement, and any other transport relatedservice. The services rendered 544 may be performed based on a smartcontract which is downloaded from or accessed via the blockchain 530 andidentified for permission to perform such services for a particular rateof exchange. The services are logged in the transaction log of thetransaction module 520, the credits 512 are transferred to the servicecenter 542 and the blockchain may log transactions to represent all theinformation regarding the recent service. In other embodiments, theblockchain 530 resides on the vehicle 120 and/or the service center 542.In one example, a transport event may require a refuel or other vehicleservice and the occupants may then be responsible for the responsibilityvalue increase for such a service. Adherence to a regular serviceschedule may be part of the adherence rate or compliance necessary toachieve an optimal user vehicle status. A service stop may/may not be apermissible action permitted by a vehicle event associated with aparticular occupant/target user, depending on their permissions.

FIG. 5C illustrates an example blockchain vehicle configuration 550 formanaging blockchain transactions conducted among various vehicles,according to example embodiments. The vehicle 120 may engage withanother vehicle 508 to perform various actions, such as to share,transfer, acquire service calls, etc. when the vehicle has reached astatus where the services need to be shared with another vehicle. Forexample, the vehicle 508 may be due for a battery charge and/or may havean issue with a tire and may be in route to pick up a package fordelivery. The vehicle 508 may notify another vehicle 120 which is in itsnetwork and which operates on its blockchain member service. The vehicle120 may then receive the information via a wireless communicationrequest to perform the package pickup from the vehicle 508 and/or from aserver (not shown). The transactions are logged in the transactionmodules 552 and 520 of both vehicles. The credits are transferred fromvehicle 508 to vehicle 120 and the record of the transferred service islogged in the blockchain 530/554 assuming that the blockchains aredifferent from one another, or, are logged in the same blockchain usedby all members.

FIG. 6 illustrates a blockchain block 600 that can be added to adistributed ledger, according to example embodiments, and contents of ablock structure 660. Referring to FIG. 6, clients (not shown) may submitentries to blockchain nodes to enact activity on the blockchain. As anexample, clients may be applications that act on behalf of a requester,such as a device, person or entity to propose entries for theblockchain. The plurality of blockchain peers (e.g., blockchain nodes)may maintain a state of the blockchain network and a copy of thedistributed ledger. Different types of blockchain nodes/peers may bepresent in the blockchain network including endorsing peers whichsimulate and endorse entries proposed by clients and committing peerswhich verify endorsements, validate entries, and commit entries to thedistributed ledger. In this example, the blockchain nodes may performthe role of endorser node, committer node, or both.

The instant system includes a blockchain which stores immutable,sequenced records in blocks, and a state database (current world state)maintaining a current state of the blockchain. One distributed ledgermay exist per channel and each peer maintains its own copy of thedistributed ledger for each channel of which they are a member. Theinstant blockchain is an entry log, structured as hash-linked blockswhere each block contains a sequence of N entries. Blocks may includevarious components such as those shown in FIG. 6. The linking of theblocks may be generated by adding a hash of a prior block's headerwithin a block header of a current block. In this way, all entries onthe blockchain are sequenced and cryptographically linked togetherpreventing tampering with blockchain data without breaking the hashlinks. Furthermore, because of the links, the latest block in theblockchain represents every entry that has come before it. The instantblockchain may be stored on a peer file system (local or attachedstorage), which supports an append-only blockchain workload.

The current state of the blockchain and the distributed ledger may bestored in the state database. Here, the current state data representsthe latest values for all keys ever included in the chain entry log ofthe blockchain. Smart contract executable code invocations executeentries against the current state in the state database. To make thesesmart contract executable code interactions extremely efficient, thelatest values of all keys are stored in the state database. The statedatabase may include an indexed view into the entry log of theblockchain, it can therefore be regenerated from the chain at any time.The state database may automatically get recovered (or generated ifneeded) upon peer startup, before entries are accepted.

Endorsing nodes receive entries from clients and endorse the entry basedon simulated results. Endorsing nodes hold smart contracts whichsimulate the entry proposals. When an endorsing node endorses an entry,the endorsing nodes creates an entry endorsement which is a signedresponse from the endorsing node to the client application indicatingthe endorsement of the simulated entry. The method of endorsing an entrydepends on an endorsement policy which may be specified within smartcontract executable code. An example of an endorsement policy is “themajority of endorsing peers must endorse the entry.” Different channelsmay have different endorsement policies. Endorsed entries are forward bythe client application to an ordering service.

The ordering service accepts endorsed entries, orders them into a block,and delivers the blocks to the committing peers. For example, theordering service may initiate a new block when a threshold of entrieshas been reached, a timer times out, or another condition. In thisexample, blockchain node is a committing peer that has received a newdata block 660 for storage on the blockchain. The ordering service maybe made up of a cluster of orderers. The ordering service does notprocess entries, smart contracts, or maintain the shared ledger. Rather,the ordering service may accept the endorsed entries and specifies theorder in which those entries are committed to the distributed ledger.The architecture of the blockchain network may be designed such that thespecific implementation of ‘ordering’ (e.g., Solo, Kafka, BFT, etc.)becomes a pluggable component.

Entries are written to the distributed ledger in a consistent order. Theorder of entries is established to ensure that the updates to the statedatabase are valid when they are committed to the network. Unlike acryptocurrency blockchain system (e.g., Bitcoin, etc.) where orderingoccurs through the solving of a cryptographic puzzle, or mining, in thisexample the parties of the distributed ledger may choose the orderingmechanism that best suits that network.

Referring to FIG. 6, a block 660 (also referred to as a data block) thatis stored on the blockchain and/or the distributed ledger may includemultiple data segments such as a block header 662, transaction specificdata 672, and block metadata 680. It should be appreciated that thevarious depicted blocks and their contents, such as block 660 and itscontents are merely for purposes of an example and are not meant tolimit the scope of the example embodiments. In some cases, both theblock header 662 and the block metadata 680 may be smaller than thetransaction specific data 672 which stores entry data, however this isnot a requirement. The block 660 may store transactional information ofN entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within the block data670. The block 660 may also include a link to a previous block (e.g., onthe blockchain) within the block header 662. In particular, the blockheader 662 may include a hash of a previous block's header. The blockheader 662 may also include a unique block number, a hash of the blockdata 670 of the current block 660, and the like. The block number of theblock 660 may be unique and assigned in an incremental/sequential orderstarting from zero. The first block in the blockchain may be referred toas a genesis block which includes information about the blockchain, itsmembers, the data stored therein, etc.

The block data 670 may store entry information of each entry that isrecorded within the block. For example, the entry data may include oneor more of a type of the entry, a version, a timestamp, a channel ID ofthe distributed ledger, an entry ID, an epoch, a payload visibility, asmart contract executable code path (deploy tx), a smart contractexecutable code name, a smart contract executable code version, input(smart contract executable code and functions), a client (creator)identify such as a public key and certificate, a signature of theclient, identities of endorsers, endorser signatures, a proposal hash,smart contract executable code events, response status, namespace, aread set (list of key and version read by the entry, etc.), a write set(list of key and value, etc.), a start key, an end key, a list of keys,a Merkel tree query summary, and the like. The entry data may be storedfor each of the N entries.

In some embodiments, the block data 670 may also store transactionspecific data 672 which adds additional information to the hash-linkedchain of blocks in the blockchain. Accordingly, the data 672 can bestored in an immutable log of blocks on the distributed ledger. Some ofthe benefits of storing such data 672 are reflected in the variousembodiments disclosed and depicted herein. The block metadata 680 maystore multiple fields of metadata (e.g., as a byte array, etc.).Metadata fields may include signature on block creation, a reference toa last configuration block, an entry filter identifying valid andinvalid entries within the block, last offset persisted of an orderingservice that ordered the block, and the like. The signature, the lastconfiguration block, and the orderer metadata may be added by theordering service. Meanwhile, a committer of the block (such as ablockchain node) may add validity/invalidity information based on anendorsement policy, verification of read/write sets, and the like. Theentry filter may include a byte array of a size equal to the number ofentries in the block data 670 and a validation code identifying whetheran entry was valid/invalid.

The above embodiments may be implemented in hardware, in a computerprogram executed by a processor, in firmware, or in a combination of theabove. A computer program may be embodied on a computer readable medium,such as a storage medium. For example, a computer program may reside inrandom access memory (“RAM”), flash memory, read-only memory (“ROM”),erasable programmable read-only memory (“EPROM”), electrically erasableprogrammable read-only memory (“EEPROM”), registers, hard disk, aremovable disk, a compact disk read-only memory (“CD-ROM”), or any otherform of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such thatthe processor may read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anapplication specific integrated circuit (“ASIC”). In the alternative,the processor and the storage medium may reside as discrete components.For example, FIG. 7 illustrates an example computer system architecture700, which may represent or be integrated in any of the above-describedcomponents, etc.

FIG. 7 is not intended to suggest any limitation as to the scope of useor functionality of embodiments of the application described herein.Regardless, the computing node 700 is capable of being implementedand/or performing any of the functionality set forth herein.

In computing node 700 there is a computer system/server 702, which isoperational with numerous other general purposes or special purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that may besuitable for use with computer system/server 702 include, but are notlimited to, personal computer systems, server computer systems, thinclients, thick clients, handheld or laptop devices, multiprocessorsystems, microprocessor-based systems, set top boxes, programmableconsumer electronics, network PCs, minicomputer systems, mainframecomputer systems, and distributed cloud computing environments thatinclude any of the above systems or devices, and the like.

Computer system/server 702 may be described in the general context ofcomputer system-executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 702 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 7, computer system/server 702 in cloud computing node700 is shown in the form of a general-purpose computing device. Thecomponents of computer system/server 702 may include, but are notlimited to, one or more processors or processing units 704, a systemmemory 706, and a bus that couples various system components includingsystem memory 706 to processor 704.

The bus represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. By way of example, and notlimitation, such architectures include Industry Standard Architecture(ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA)bus, Video Electronics Standards Association (VESA) local bus, andPeripheral Component Interconnects (PCI) bus.

Computer system/server 702 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 702, and it includes both volatileand non-volatile media, removable and non-removable media. System memory706, in one embodiment, implements the flow diagrams of the otherfigures. The system memory 706 can include computer system readablemedia in the form of volatile memory, such as random-access memory (RAM)710 and/or cache memory 712. Computer system/server 702 may furtherinclude other removable/non-removable, volatile/non-volatile computersystem storage media. By way of example only, storage system can beprovided for reading from and writing to a non-removable, non-volatilemagnetic media (not shown and typically called a “hard drive”). Althoughnot shown, a magnetic disk drive for reading from and writing to aremovable, non-volatile magnetic disk (e.g., a “floppy disk”), and anoptical disk drive for reading from or writing to a removable,non-volatile optical disk such as a CD-ROM, DVD-ROM or other opticalmedia can be provided. In such instances, each can be connected to thebus by one or more data media interfaces. As will be further depictedand described below, memory 706 may include at least one program producthaving a set (e.g., at least one) of program modules that are configuredto carry out the functions of various embodiments of the application.

Program/utility having a set (at least one) of program modules, may bestored in memory 706 by way of example, and not limitation, as well asan operating system, one or more application programs, other programmodules, and program data. Each of the operating system, one or moreapplication programs, other program modules, and program data or somecombination thereof, may include an implementation of a networkingenvironment. Program modules generally carry out the functions and/ormethodologies of various embodiments of the application as describedherein.

As will be appreciated by one skilled in the art, aspects of the presentapplication may be embodied as a system, method, or computer programproduct. Accordingly, aspects of the present application may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present application may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Computer system/server 702 may also communicate with one or moreexternal devices via an I/O adapter 720, such as a keyboard, a pointingdevice, a display, etc.; one or more devices that enable a user tointeract with computer system/server 702; and/or any devices (e.g.,network card, modem, etc.) that enable computer system/server 702 tocommunicate with one or more other computing devices. Such communicationcan occur via I/O interfaces via adapter 720. Still yet, computersystem/server 702 can communicate with one or more networks such as alocal area network (LAN), a general wide area network (WAN), and/or apublic network (e.g., the Internet) via a network adapter. The networkadapter communicates with the other components of computer system/server702 via a bus. It should be understood that although not shown, otherhardware and/or software components could be used in conjunction withcomputer system/server 702. Examples, include, but are not limited to:microcode, device drivers, redundant processing units, external diskdrive arrays, RAID systems, tape drives, and data archival storagesystems, etc.

Although an exemplary embodiment of at least one of a system, method,and non-transitory computer readable medium has been illustrated in theaccompanied drawings and described in the foregoing detaileddescription, it will be understood that the application is not limitedto the embodiments disclosed, but is capable of numerous rearrangements,modifications, and substitutions as set forth and defined by thefollowing claims. For example, the capabilities of the system of thevarious figures can be performed by one or more of the modules orcomponents described herein or in a distributed architecture and mayinclude a transmitter, receiver or pair of both. For example, all orpart of the functionality performed by the individual modules, may beperformed by one or more of these modules. Further, the functionalitydescribed herein may be performed at various times and in relation tovarious events, internal or external to the modules or components. Also,the information sent between various modules can be sent between themodules via at least one of: a data network, the Internet, a voicenetwork, an Internet Protocol network, a wireless device, a wired deviceand/or via plurality of protocols. Also, the messages sent or receivedby any of the modules may be sent or received directly and/or via one ormore of the other modules.

One skilled in the art will appreciate that a “system” could be embodiedas a personal computer, a server, a console, a personal digitalassistant (PDA), a cell phone, a tablet computing device, a smartphoneor any other suitable computing device, or combination of devices.Presenting the above-described functions as being performed by a“system” is not intended to limit the scope of the present applicationin any way but is intended to provide one example of many embodiments.Indeed, methods, systems and apparatuses disclosed herein may beimplemented in localized and distributed forms consistent with computingtechnology.

It should be noted that some of the system features described in thisspecification have been presented as modules, in order to moreparticularly emphasize their implementation independence. For example, amodule may be implemented as a hardware circuit comprising custom verylarge-scale integration (VLSI) circuits or gate arrays, off-the-shelfsemiconductors such as logic chips, transistors, or other discretecomponents. A module may also be implemented in programmable hardwaredevices such as field programmable gate arrays, programmable arraylogic, programmable logic devices, graphics processing units, or thelike.

A module may also be at least partially implemented in software forexecution by various types of processors. An identified unit ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions that may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified module need not be physically locatedtogether but may comprise disparate instructions stored in differentlocations which, when joined logically together, comprise the module andachieve the stated purpose for the module. Further, modules may bestored on a computer-readable medium, which may be, for instance, a harddisk drive, flash device, random access memory (RAM), tape, or any othersuch medium used to store data.

Indeed, a module of executable code could be a single instruction, ormany instructions, and may even be distributed over several differentcode segments, among different programs, and across several memorydevices. Similarly, operational data may be identified and illustratedherein within modules and may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork.

It will be readily understood that the components of the application, asgenerally described and illustrated in the figures herein, may bearranged and designed in a wide variety of different configurations.Thus, the detailed description of the embodiments is not intended tolimit the scope of the application as claimed but is merelyrepresentative of selected embodiments of the application.

One having ordinary skill in the art will readily understand that theabove may be practiced with steps in a different order, and/or withhardware elements in configurations that are different than those whichare disclosed. Therefore, although the application has been describedbased upon these preferred embodiments, it would be apparent to those ofskill in the art that certain modifications, variations, and alternativeconstructions would be apparent.

While preferred embodiments of the present application have beendescribed, it is to be understood that the embodiments described areillustrative only and the scope of the application is to be definedsolely by the appended claims when considered with a full range ofequivalents and modifications (e.g., protocols, hardware devices,software platforms etc.) thereto.

What is claimed is:
 1. A method, comprising: identifying a target device has entered a transport and has initiated a transport event at a target location; applying permissions, associated with the target device, to the transport event; determining a transport event modification has occurred, when the transport has stopped moving for a predetermined period of time and one or more transport operations have occurred, prior to arriving at a transport event destination; determining whether the permissions permit the transport event modification; and notifying one or more registered devices associated with the target device of the transport event modification.
 2. The method of claim 1, further comprising: receiving a request to perform the transport event modification during the transport event; determining whether the request originated from one or more of the registered devices; and responsive to determining the request originated from one or more of the registered devices, permitting the transport event modification.
 3. The method of claim 2, further comprising: responsive to permitting the transport event modification, adding another destination location to the transport event as a next destination for the transport; and determining an estimated amount of transport stop time and one or more of the transport operations which are expected to occur during the transport stop time.
 4. The method of claim 3, further comprising: identifying the transport has arrived at the next destination; determining whether an amount of transport stop time has exceeded the estimated amount of transport stop time; determining whether the one or more expected transport operations have occurred during the transport stop time; and notifying one or more of the registered devices when at least one of the amount of transport stop time has exceeded the estimated amount of transport stop time and at least one prohibited transport operation has occurred during the transport stop time.
 5. The method of claim 1, further comprising: receiving a request to perform the transport event modification during the transport event; determining the request originated from the target device; determining the request comprises a modified destination; retrieving a user device profile associated with a user device associated with the modified destination; transmitting a request for confirmation of the transport event modification to the user device associated with the modified destination; transmitting a request for permission to the one or more registered devices; and responsive to receiving a confirmation from the user device associated with the modified destination and a permission response from the one or more registered devices, permitting the transport event modification.
 6. The method of claim 1, further comprising: retrieving a smart contract from a distributed ledger; invoking the smart contract responsive to identifying the transport event; and determining, from the smart contract, the target device requires a specific category of transport and is permitted to be transported to one or more identified destination locations.
 7. The method of claim 6, further comprising: creating a blockchain transaction comprising a date of the transport event, a time of the transport event, the target location, a transport event destination and transport identification information; and storing the blockchain transaction in the distributed ledger.
 8. A system, comprising: a server configured to: identify a target device has entered a transport and has initiated a transport event at a target location; apply permissions, associated with the target device, to the transport event; determine a transport event modification has occurred, when the transport has stopped movement for a predetermined period of time and one or more transport operations have occurred, prior to arrival at a transport event destination; determine whether the permissions permit the transport event modification; and notify one or more registered devices associated with the target device of the transport event modification.
 9. The system of claim 8, the server configured to: receive a request to perform the transport event modification during the transport event; determine whether the request originated from one or more of the registered devices; and responsive to determination that the request originated from one or more of the registered devices, permit the transport event modification.
 10. The system of claim 9, the server configured to: responsive to permit the transport event modification, add another destination location to the transport event as a next destination for the transport; and determine an estimated amount of transport stop time and one or more of the transport operations which are expected to occur during the transport stop time.
 11. The system of claim 10, the server configured to: identify the transport has arrived at the next destination; determine whether an amount of transport stop time has exceeded the estimated amount of transport stop time; determine whether the one or more expected transport operations have occurred during the transport stop time; and notify one or more of the registered devices when at least one of the amount of transport stop time has exceeded the estimated amount of transport stop time and at least one prohibited transport operation has occurred during the transport stop time.
 12. The system of claim 9, the server configured to: receive a request to perform the transport event modification during the transport event; determine the request originated from the target device; determine the request comprises a modified destination; retrieve a user device profile associated with a user device associated with the modified destination; transmit a request for confirmation of the transport event modification to the user device associated with the modified destination; transmit a request for permission to the one or more registered devices; and responsive to receive a confirmation from the user device associated with the modified destination and a permission response from the one or more registered devices, permit the transport event modification.
 13. The system of claim 8, the server configured to: retrieve a smart contract from a distributed ledger; invoke the smart contract responsive to the identified transport event; and determine, from the smart contract, the target device requires a specific category of transport and is permitted to be transported to one or more identified destination locations.
 14. The system of claim 13, the server configured to: create a blockchain transaction comprising a date of the transport event, a time of the transport event, the target location, a transport event destination and transport identification information; and store the blockchain transaction in the distributed ledger.
 15. A non-transitory computer readable medium comprising instructions, that when read by a processor, cause the processor to perform: identifying a target device has entered a transport and has initiated a transport event at a target location; applying permissions, associated with the target device, to the transport event; determining a transport event modification has occurred, when the transport has stopped moving for a predetermined period of time and one or more transport operations have occurred, prior to arriving at a transport event destination; determining whether the permissions permit the transport event modification; and notifying one or more registered devices associated with the target device of the transport event modification.
 16. The non-transitory computer readable medium of claim 15, further comprising: receiving a request to perform the transport event modification during the transport event; determining whether the request originated from one or more of the registered devices; and responsive to determining the request originated from one or more of the registered devices, permitting the transport event modification.
 17. The non-transitory computer readable medium of claim 16, further comprising: responsive to permitting the transport event modification, adding another destination location to the transport event as a next destination for the transport; and determining an estimated amount of transport stop time and one or more of the transport operations which are expected to occur during the transport stop time.
 18. The non-transitory computer readable medium of claim 17, further comprising: identifying the transport has arrived at the next destination; determining whether an amount of transport stop time has exceeded the estimated amount of transport stop time; determining whether the one or more expected transport operations have occurred during the transport stop time; and notifying one or more of the registered devices when at least one of the amount of transport stop time has exceeded the estimated amount of transport stop time and at least one prohibited transport operation has occurred during the transport stop time.
 19. The non-transitory computer readable medium of claim 15, further comprising: receiving a request to perform the transport event modification during the transport event; determining the request originated from the target device; determining the request comprises a modified destination; retrieving a user device profile associated with a user device associated with the modified destination; transmitting a request for confirmation of the transport event modification to the user device associated with the modified destination; transmitting a request for permission to the one or more registered devices; and responsive to receiving a confirmation from the user device associated with the modified destination and a permission response from the one or more registered devices, permitting the transport event modification.
 20. The non-transitory computer readable medium of claim 15, further comprising: retrieving a smart contract from a distributed ledger; invoking the smart contract responsive to identifying the transport event; and determining, from the smart contract, the target device requires a specific category of transport and is permitted to be transported to one or more identified destination locations. 